/triage accepted

I typically would not prefer to add a binary to our release artifacts that has already been removed from kubectl because of its dependencies. However, I also understand that kubectl-convert is pretty tightly coupled to k8s versions. I wonder how we feel about this compared to something like kubeadm, which has seen some motivation to be moved out of k/k.

while we had plans to move kubeadm out of k/k the preference was to still continue releasing it as part of the k8s bundle.

kubectl-convert is difficult because the same reason it was broken out from kubectl (dependency on internal types) seems to be the primary motivation for including it in k/k release process. Would like to discuss more before we commit to releasing as part of k/k because we are trying to minimize churn on the artifacts we are producing.

i'm +1 on including kubectl-convert in the release, or if not kubectl-convert, a general mechanism to allow users to migrate their manifests on disk away from a unsupported API.

Another thing to note is that we should actively be testing artifacts that are part of the k/k release bundles. Do we have periodic jobs exercising kubectl-convert functionality?

+1 to @hasheddan's assessment. Will hold any comments from my side pending response.
/area release-eng

kubectl-convert is difficult because the same reason it was broken out from kubectl (dependency on internal types) seems to be the primary motivation for including it in k/k release process.

Pairing kubectl-convert to the same release process as kube-apiserver makes sense to me, because that is the cadence at which changes to built-in types and conversion logic are released. The command is useful when users need to migrate their manifests from a deprecated version to a stable version. Requiring users to compile their own instance doesn't seem reasonable, so I think it should be built/released somehow.

That said, if the goal of kubectl cutting k8s.io/kubernetes dependencies was to allow it to have its own release, putting a new artifact explicitly coupled to the kube-apiserver release in the same bundle as kubectl seems like backtracking.

Another thing to note is that we should actively be testing artifacts that are part of the k/k release bundles. Do we have periodic jobs exercising kubectl-convert functionality?

+1 to testing.

Another thing to note is that we should actively be testing artifacts that are part of the k/k release bundles. Do we have periodic jobs exercising kubectl-convert functionality?

We used to have some test in test-cmd suite, lemme ensure they are properly testing kubectl-convert.

Now with convert test in 2nd commit.

/approve

(/build and /hack changes look good)

/retest

(Will drop an /approve for build/ on this once the verify test passes.)

(Will drop an /approve for build/ on this once the verify test passes.)

Fixed all the bits, should be good now.

/lgtm
/approve

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dims, justaugustus, soltysh

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Relevant to kubernetes/website#28724: Document how to install kubectl convert plugin